The reason why select from #1810 wasn't working was because there was a discrepancy between the name element in the Field struct of the struct get expression and the name() method of the expression.

This PR is a quick fix to that behavior for that specific expression, but ideally we would want to consolidate the logic between Expr::to_field and Expr::name so that there aren't two code paths for getting the name of an expression. The problem behind that is Expr::to_field takes in a schema, which is not always easily obtainable during the calls we make in the code to Expr::name. Notably, Python code in the physical plan and execution step generally do not use the schema, but do use expression names. Thus always requiring a schema for Expr::name would not work.

This raises the question: would a schema ever affect the name of an expression? The conclusion from a conversation with @clarkzinzow and @jaychia was no. Thus, would it be reasonable to separate the name from an expression's field, so that Expr::name was the single source of truth?

Moreover, in the future we would like to do table-scoped columns so that we are able to construct expressions that take data from multiple tables. Once we do that, it should be possible to derive the dtype of an expression by determining the dtypes of the columns or literals which are leaves in the expression tree. Then, we wouldn't even need to pass around a schema altogether?

Anyway, lots to think about. We'll leave this as tech debt that should be reworked when implement table-scoped columns, since that will likely require rethinking a lot about schemas and expressions as well.